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1.  Introduction 

An  earlier  investigation  into  the  integration  of  structured  and  formal  methods  for  the 
production  of  requirements  specifications  [1]  led  to  the  conclusion  that  further  work  is 
needed  in  all  areas  of  the  requirements  definition  activity.  One  recommendation  in 
particular  suggested  that  the  translation  of  data  flow  diagrams  into  the  formal  language  Z 

[2]  should  be  researched  and  rules  derived.  This  report  describes  the  results  of  that 
research.  Data  flow  diagrams  were  chosen  for  further  study  as  they  are  in  common  use  as 
a  means  of  describing  an  existing  or  required  system,  but  little  work  has  been  carried  out 
in  finding  a  mathematical  basis  for  them.  They  feature  in  several  systems  analysis  and 
design  methods,  including  SSADM  (Structured  Systems  Analysis  and  Design  Method) 

[3] ,  Yourdon  [4]  and  CORE  (Controlled  Requirements  Expression)  [51,  albeit  in  different 
forms. 

The  advantage  in  providing  a  mathematical  basis  for  data  flow  diagrams  is  that  they  will 
become  unambiguous  with  a  defined  meaning,  at  the  same  time  as  retaining  their  ease  of 
understanding.  Diagrams  are  often  easier  to  understand  than  a  mathematical  specification 
as  the  latter  may  appear  daunting  at  first  sight.  This  report,  by  providing  a  mathematical 
basis,  imposes  one  view  of  data  flow  diagrams,  and  this  will  be  explained  as  the 
formalism  is  developed. 

The  original  recommendation  to  translate  data  flow  diagrams  into  Z  has  been  extended 
and  there  are  now  three  parts  to  the  work.  The  first  part  is  to  produce  rules  for  the 
translation  of  a  data  flow  diagram  into  an  outline  Z  specification,  which  gives  a  precise 
meaning  to  the  diagram,  and  could  be  used  in  a  formal  development,  if  required.  The 
second  part  is  to  give  a  formal  relationship  between  data  flow  diagrams  and  Z 
specifications,  which  says  what  it  means  for  a  diagram  and  a  Z  specification  to  represent 
the  same  system.  The  final  pan  is  to  give  rules  for  generating  a  data  flow  diagram  from  a 
Z  specification  which  may  be  used  to  illustrate  and  validate  die  specification. 

This  repon  has  used  the  SSADM  conventions  for  data  flow  diagrams,  although  the  work 
is  more  widely  applicable  with  some  minor  modifications.  For  example,  additional 
constraints  could  be  put  on  a  diagram  to  incorporate  desired  features  or  a  house-style. 

The  repon  is  structured  as  follows.  Section  2  formally  specifies  data  flow  diagrams  in  Z. 
This  is  needed  before  any  rules  can  be  defined.  The  required  parts  of  Z  are  specified  in 
Section  3,  again  in  Z  itself.  Die  rules  for  translating  a  data  flow  diagram  into  a  Z 
specification  are  given  in  Section  4.  Section  5  describes  how  to  check  that  a  Z 
specification  and  a  data  flow  diagram  represent  the  same  system.  Section  6  presents  the 
rules  for  generating  a  data  flow  diagram  from  a  Z  specification,  and  the  final  section 
contains  some  concluding  remarks. 

This  report  has  been  produced  using  the  RSRE  Z  tool  Zadok  [7].  Zadok  is  a  Z  editor  and 
also  a  syntax-  and  type-checker.  Sections  2  to  6  of  this  report  are  separate  Z  documents. 
The  conclusion  of  each  document  is  marked  by  a  "keeps"  statement  which  lists  the 
identifiers  exported  by  the  document.  A  document  is  imported  into  another  one  by 
including  the  document  name,  which  is  distinguished  by  having  a  box  drawn  round  it 

2.  The  Specification  of  Data  Flow  Diagrams 


In  SSADM,  data  flow  diagrams  have  three  types  of  diagram  element.  These  are  external 
entities,  processes,  and  datastores.  External  entities  are  those  entities  outside  the  system 
boundary  from  which  data  is  input  to  the  system,  or  to  where  data  from  the  system  is 
output.  Processes  take  a  set  of  inputs  which  are  transformed  by  the  process  into  a  set  of 
outputs.  Die  processes  cany  out  the  functions  of  the  system.  Processes  are  sometimes 
referred  to  as  transformers.  Datastores,  as  their  name  implies,  store  the  data  held  in  the 
system. 

External  entities  are  represented  graphically  in  SSADM  by  circles,  processes  by  squares, 
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and  datastores  by  two  horizontal  parallel  lines  joined  on  the  left  hand  side  by  a  vertical 
line.  Data  flows  show  data  moving  around  the  system.  They  are  represented  by  arrows, 
labelled  with  the  name  of  the  data.  The  head  of  the  arrow  indicates  die  destination  of  the 
data.  Each  data  flow  joins  two  diagram  elements  together,  with  the  constraints  that  a  data 
flow  cannot  begin  and  end  at  the  same  entity,  and  every  data  flow  must  have  a  process  as 
either  its  source  or  its  destination  or  both. 

The  interpretation  put  on  a  data  flow  diagram  in  this  report  is  that  it  represents  operations 
being  carried  out  on  a  state.  The  state  is  represented  by  the  datastores,  and  the  operations 
by  the  processes.  The  external  entities  just  provide  or  receive  data.  In  formalizing  this 
interpretation  in  Z,  specifications  are  needed  of  the  relevant  details  of  data  flow  diagrams 
and  of  Z.  A  meaning  function  may  then  be  defined  from  data  flow  diagrams  to  Z.  This 
function  represents  the  interpretation. 

To  specify  data  flow  diagrams,  it  is  necessary  to  abstract  away  from  the  detail  of  the 
diagrams.  External  entities,  processes  and  datastores  will  be  specified  first,  and  then  the 
data  flows  between  them  may  be  specified  as  constraints  on  the  set  of  diagram  elements 
making  up  a  given  diagram. 

Figure  1  shows  an  example  of  a  data  flow  diagram,  using  the  conventions  of  SSADM. 
This  diagram  shows  pan  of  a  banking  system,  where  a  manager  takes  the  name  of  a  new 
customer  and  adds  it  to  a  database  containing  the  names  of  the  current  customers.  This 
example  will  be  used  throughout  this  section  to  illustrate  the  specification  of  data  flow 
diagrams. 

identifier  «*  seq  Char 

texternal_entity  t 

names  :  F  identifier 

The  relevant  part  of  an  external  entity,  from  the  point  of  view  of  this  interpretation,  is  the 
data  which  it  gives  rise  to  or  uses.  The  data  moving  around  the  system  is  shown  by 
writing  the  name  of  the  data,  its  identifier,  on  the  data  flow. 

The  example  data  flow  diagram  has  one  external  entity,  namely  the  customer. 

I  Customer  :  external_entity 


l  Customer. names  -  { ”Customer_name”} 

The  data  associated  with  the  entity  is  just  the  customer’s  name. 

Each  process  takes  in  inputs,  and  produces  outputs,  in  accordance  with  some  rules.  These 
rules  are  represented  by  the  name  of  the  process.  There  are  two  sorts  of  input:  those  from 
outside  of  the  system,  that  is,  from  external  entities,  and  those  from  within  the  system, 
that  is,  data  passed  between  processes  directly.  These  are  distinguished,  by  inputs  and 
int^inputs  respectively.  Similarly,  there  are  two  sorts  of  output  which  are  also 
distinguished. 

_  process  | 

I  inputs,  outputs  :  seq  identifier 
I  int^inputs,  int_outputs  :  seq  identifier 
I  process_name  :  seq  Char 


The  inputs  and  outputs  are  treated  as  sequences  rather  than  sets  as  this  makes  the 
translation  rules  more  straightforward.  The  ordering  can  be  thought  of  as  "across  the  page 
from  left  to  right".  The  sequence  does  not  imply  a  particular  order  for  processing  any 
more  than  the  diagram  does.  Flows  of  data  between  processes  and  datastores  are  not 
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interpreted  as  inputs  or  outputs  (of  any  form)  as  they  actually  represent  a  change  of  the 
state  data. 

The  example  data  flow  diagram  has  one  process,  "Register_new_Customer",  which  has 
one  input  from  an  external  entity,  "Customer_name",  and  no  internal  inputs  or  any 
outputs.  Hie  arrow  on  the  diagram  from  the  process  to  the  datastore  indicates  that  die 
operation  to  register  a  new  customer  causes  a  change  to  the  datastore,  and  is  'Jierefore  not 
an  output 

p  :  process 

p.  inputs  -  <  " Customer_name "  ) 
p. outputs  -  0 
p.int_inputs  «  0 
p.int_outputs  m  0 

p . process_name  «  "Register_new_Customer" 

The  processes  in  a  SSADM  data  flow  diagram  have  two  extra  pieces  of  information 
associated  with  them,  a  numeric  identifier  and  a  location.  The  numeric  identifier  is 
unnecessary,  as  it  is  assumed  that  no  two  processes  have  the  same  name.  The  location 
does  add  something  to  the  specification,  if  it  is  interpreted  as  describing  a  role.  That  is, 
states  the  authority  needed  to  carry  out  the  process.  However,  this  information  is  not 
appropriate  to  incorporate  into  the  Z  specification  produced  by  this  translation. 

[datastore  < 

store_name  :  seq  Char 


Datastores  are  named.  The  contents  of  stores  do  not  appear  on  a  data  flow  diagram,  so  no 
contents  are  specified. 

The  example  data  flow  diagram  has  one  datastore  called  "Customers". 

|  d  :  datastore 


I  d.store_name  -  " Customers ” 

The  identifier  "Dl"  is  not  recorded  as  it  is  assumed  that  datastores  with  the  same  name 
are  the  same,  so  the  identifier  adds  nothing. 

DFD_element  ext  *  externaljentity  » 

I  proc  <(  process  # 

I  store  <(  datastore  » 

The  three  schemas  extemai_entity,  process,  and  datastore  represent  the  three 
possible  type  of  data  flow  diagram  element.  In  addition  to  diagram  elements,  a  data  flow 
diagram  contains  data  flows: 

_  data_flo w  | 

I  origin,  destination  :  DFD_element 
I  label  :  seq  Char 


origin  *  destination 

origin  €  rng  proc  v  destination  e  rng  proc 

1 

Each  data  flow  has  a  source  and  destination,  both  of  which  are  diagram  elements.  Each  is 
also  labelled  with  the  name  of  the  data  flowing  along  it.  A  data  flow  cannot  return  to  its 
own  origin,  and  must  have  a  process  as  either  its  origin  or  destination  (or  both). 
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Hie  example  data  flow  diagram  has  two  data  flows,  from  the  external  customer  to  the 
process,  and  from  the  process  to  the  datastore. . 


dfl  :  data_flow 

dfl . origin  m  ext ( Customer ) 
dfl. destination  -  proc(p) 
dfl. label  m  "Customer  name" 


df2  :  data  flow 


df  2.  origin  -  proc(p) 

df 2. destination  «  store (d) 

df 2. label  -  "" 


The  first  data  flow,  from  the  external  customer  to  the  process,  is  labelled  with  the  name 
of  the  data  concerned,  that  is,  the  customer’s  name.  The  second  flow,  however,  represents 
a  change  of  the  state  data  held  in  the  datastore,  and  is  not  labelled. 

A  well-formed  data  flow  diagram  consists  of  diagram  elements  connected  by  suitable 
data  flows. 

DFD _ 

elements  :  IF  DFD_element 
flows  :  F  data_flow 

V  e  :  elements  •  (  3  f  :  flows  •  e  *»  f .origin  v  e  -  f .destination  ) 

V  f  :  flows  •  <  f .origin  €  elements  a  f .destination  e  elements  ) 

V  e  :  elements;  ex  :  external  entity  I  e  “  ext  ex  • 
ex. names  -  {  f  :  flows  I  e  •  7.  origin  v  e  ■  f .destination  •  f. label  ) 

V  e  :  elements;  p  :  process  I  e  m  proc  p  • 
mg  (p.  inputs)  -  /  f  :  flows 

I  f  .destination  -  e  a  f.  origin  e  mg  ext 
•  f. label  } 

mg  (p.  outputs)  -  (  f  :  flows 

I  f. origin  -  e  a  f .destination  e  mg  ext 
•  f. label  ) 

mg  (p.int_inputs)  -  {  f  :  flows 

I  f .destination  -  e  a  f .origin  e  rng  proc 
•  f. label  } 

rng  (p.int_outputs)  -  {  f  :  flows 

I  f. origin  -  e  a  f .destination  e  rng  proc 
•  f. label  } 


The  first  predicate  says  that,  for  each  element  in  the  diagram,  there  must  be  a  flow  either 
to  or  from  it,  or  both.  The  second  says  that  all  flows  must  come  from  and  go  to  a  diagram 
element.  These  are  basic  constraints  to  say  that  the  diagram  must  be  partly  connected. 
Additional  constraints  could  be  added  to  say  that  the  diagram  must  contain  no  sources 
and  sinks  of  data,  or  that  the  diagram  must  be  completely  connected  (that  is,  is  not 
capable  of  being  split  into  two  or  more  sets  of  elements,  with  no  data  flows  between  any 
two  elements  in  different  sets). 

The  third  and  fourth  predicates  describe  two  checks  that  must  be  made  on  each  data  flow 
diagram,  to  ensure  that  the  representation  in  terms  of  elements  and  data  flows  is 
consistent.  The  first  check  is  that,  for  each  external  entity,  the  names  associated  with  it 
correspond  to  the  labels  on  the  data  flows  going  to  or  coming  from  that  entity.  The 
second  check  is  concerned  with  processes.  For  each  process,  the  inputs  associated  with 
the  process  must  correspond  to  the  labels  on  the  data  flows  from  an  external  entity  to  the 
process,  and  the  outputs  associated  with  the  process  must  correspond  to  the  labels  on  the 
data  Hows  from  the  process  to  an  external  entity.  Similarly,  for  each  process,  the  internal 
inputs  associated  with  the  process  must  correspond  to  the  labels  on  the  data  flows  from 
another  process  to  the  process,  and  the  internal  outputs  associated  with  the  process  must 
correspond  to  the  labels  on  the  data  flows  from  the  process  to  another  process. 

The  bank  diagram  is  composed  of  one  external  entity,  one  process  and  one  datastore, 
together  with  two  data  flows. 
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Bank  :  DFD 


I  Bank. elements  -  (ext (Customer) ,  proc(p),  store (d) ) 

Bank. flows  «*  (dfl,  d£2 ) 

This  diagram  is  consistent,  as  the  only  input  to  the  "Register_new_Customer"  process  is  a 
"Customer_name",  which  is  the  same  as  the  label  on  the  data  flow  from  the  external 
Customer  to  die  process.  Also,  the  external  Customer  has  only  one  type  of  data 
associated  with  it  which  is  the  same  as  the  label  on  the  only  data  flow  from  it.  There  are 
no  data  flows  to  the  Customer. 

Data_flow_diagram  keeps  identifier,  external_entity,  process,  datastore, 

ext,  proc,  store,  DFD_element,  data_flow,  DFD, 
Customer,  p,  d,  dfl,  d£2,  Bank 
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Figure  1  An  Example  Data  Flow  Diagram 
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3.  The  Specification  of  Z 


Data_flow_diagram  Module 


The  purpose  of  this  section  is  to  specify  those  parts  of  Z  that  will  be  needed  to  represent 
any  data  flow  diagram.  For  die  interpretation  used,  only  two  constructs  are  needed, 
namely  given  sets  and  schemas. 

A  given  set  introduces  a  Z  type.  This  type  is  constructed  from  the  name  of  the  set. 
set  ■■  seq  Char 

The  name  of  the  set  is  just  a  sequence  of  characters. 

Schemas  are  more  complicated  and  have  three  parts:  a  name,  a  signature  and  a  predicate. 


schema_name  mm  seq  Char 

The  name  of  the  schema  is  just  a  sequence  of  characters. 

The  signature  of  a  schema  is  a  more  complicated  structure.  There  are  two  sorts  of 
element  in  a  signature,  inclusions  and  declarations.  Inclusions  are  names  of  other 
schemas  to  be  included,  and  declarations  are  identifier-type  pairs.  Identifiers  have  already 
been  defined  as  sequences  of  characters.  Types  are  more  difficult. 

The  definitions  of  types  and  signatures  are  mutually  recursive,  so  a  set  of  types  is 
introduced  first  as  a  given  set,  and  then  later  constrained. 

[  type  ] 

signature_element  inc  «  schema_name  »  /  dec  #  (  identifier  x  type  )  » 

signature  mm  F  signature_element 

A  signature  is  a  set  of  inclusions  and  declarations. 

type  given  «  seq  Char  » 

I  tuple  V.  seq  type  » 

I  powerset  H  type  » 

I  schema_type  «  signature  » 

There  are  four  sorts  of  types  in  Z:  those  constructed  from  given  sets,  tuples  (which  arise 
from  cross-products),  powersets  (for  example,  signature  above  has  a  powerset  type), 
and  schema  types.  For  example,  the  following  schema: 

[example  , 

a  ;  M;  b  :  seq  M 

has  the  following  type: 

schema_type  { dec  <  a,  given  f  Rl  ;  ), 

dec  (  b,  tuple  <  given  (  W  ),  given  <  M  )  )  ;  ) 

The  predicate  part  of  a  schema  is  straightforward. 

[  predicate  ] 

I  empty  :  predicate 
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Nothing  is  said  about  predicates,  other  than  that  they  exist,  as  they  cannot  be  deduced 
from  a  data  flow  diagram.  For  the  translation  from  data  flow  diagrams  to  Z,  the  empty 
predicate  is  supplied. 

_  schema  . 

n  :  schema_name 
sig  :  signature 
pred  :  predicate 

1 

A  schema  has  a  name,  a  signature  and  a  predicate. 

z_element  : given__set  t  set  »  /  box  tt  schema  a 
Each  element  of  the  part  of  Z  used  is  either  a  given  set  or  a  schema  box. 
z_specification  —  F  z_element 
A  Z  specification  will  consist  of  a  set  of  these  elements. 

Z_specification  keeps  set,  schema_name,  signature,  signature_element, 

inc,  dec,  type,  given,  tuple,  powerset, 
schema_type,  predicate,  empty,  schema,  z_element, 
given_set,  box,  z_specification 
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4.  Rules  for  Translating  a  Data  Flow  Diagram  into  a  Z  Specification 


Data_flow_diagram  :Module 
Z_spccification  Module 


This  section  defines  a  function,  translate,  which  translates  a  data  flow  diagram  into  a  Z 
specification.  Each  element  of  the  diagram  is  translated  into  one  or  more  Z  elements: 
external  entities  are  translated  into  given  sets,  processes  into  schemas  defining  operations 
on  states,  and  datastores  into  schemas  defining  part  of  the  state.  A  given  diagram  element 
and  its  translation  are  gathered  together  in  the  following  schema  along  with  the  diagram 
being  translated: 

_  trans_/>ars  .  . 

1  d_e  :  DFD_element 
z_e  :  W  z^element 
I  diagram  :  DFD 


d_e  €  diagram. elements 

■ 

Taking  external  entities  first,  a  given  set  is  produced  for  each  type  of  data  associated  with 
that  entity.  These  sets  represent  the  types  of  the  inputs  and  outputs  to  the  system,  and 
their  names  are  given  by  appending  "_type"  to  the  names  of  the  data. 


trans_ext  ■ 

trans_pars 

d_e  e  rng  ext 

zje  -  given_set  (  {  n  :  (ext"1  d_e)  .names  •  n  "  ”_type”  }  1 


Using  the  bank  example,  the  external  entity  "Customer"  produces  one  given  set, 
"Customer_name_type".  This  set  represents  the  only  type  of  input  to  the  system,  and 
there  are  no  outputs. 

A  schema  is  generated  for  each  process  and  describes  the  effect  the  operation  represented 
by  the  process  has  on  the  state  of  the  system,  that  is,  which  datastores  are  affected. 
Additional  given  sets  are  generated  for  internal  inputs  and  outputs. 
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_  trans_proc 
I  t rans_pars 


d_e  -  proc  C  ©process  ) 
z_e  m  (  box  (  0 schema  )  }  u 

given_set  I  {  i  :  mg  int_inputs  u  mg  int_outputs  •  i  “  "_type"  }  I 
where 

I  schema;  process 


n  »  process_name 

sig  m  {  data_flow;  datastore 

I  0 data_flow  e  diagram,  flows 

store (  Odatastore  )  e  diagram. elements 
destination  «  d_e  a  origin  -  store  f  Odatastore  > 

-if  B  data  flow '  /  0data_flow'  €  diagram,  flows 
•  origTn'  -  d_e  a  destination'  “  origin  > 

•  inc  f  "S"  *  store_name  j  ) 
u 

{  data_flow;  datastore 
I  Qdata_flow  e  diagram. flows 

store  <  Odatastore  )  e  diagram. elements 

origin  -  d  e  a  destination  -  store  f  Odatastore  ) 

•  inc  <  "A""*  store_name  )  ) 
u 

{  i  :  dom  inputs 

•  dec  (  inputs  i  “  given  (  inputs  i  m  ”_type "  )  )  } 

u 

{  i  :  dom  outputs 

•  dec  (  outputs  i  “  given  <  outputs  i  “  ”_type”  )  )  } 

u 

{  i  :  dom  int_inputs 

•  dec  f  int_inputs  i,  given  (  int_inputs  i  “  "_type"  )  )  } 
u 

{  i  :  dom  int_outputs 

•  dec  (  int_outputs  i,  given  (  int_outputs  i  “  "_type"  )  )  } 
pred  *  empty 


The  name  of  the  generated  schema  is  the  same  as  the  process  name,  and  its  signature 
consists  of  those  datastores  which  are  read  by  the  process  but  not  altered  in  any  way, 
those  datastores  which  the  process  does  affect,  and  the  inputs  and  outputs,  both  external 
and  internal.  Those  datastores  read  but  not  changed  are  prefixed  by  "Z”,  while  those  that 
are  changed  are  prefixed  by  "A".  The  datastores  that  are  read  but  not  changed  by  a 
process  are  found  by  looking  for  datastores  in  the  diagram  which  have  a  data  flow  from 
them  to  the  process,  but  for  which  there  is  no  flow  from  the  process  back  to  the  datastore. 
Each  datastore  which  is  a  destination  of  a  dataflow  is  changed.  Datastores  become 
inclusions  in  the  signature. 

Each  input  is  decorated  with  a "?",  and  each  output  with  a  "!".  Internal  inputs  and  outputs 
are  not  decorated.  All  the  inputs  and  outputs,  both  internal  and  external,  become 
declarations  in  the  signature.  Their  types  are  found  by  adding  "_type"  to  the  name  and 
making  the  resulting  name  into  a  given  set.  If  there  were  two  data  flows  to  or  from  the 
process  with  the  same  name,  this  name  would  appear  only  once  in  the  signature  of  the 
process.  This  is  a  reasonable  approach  as  it  is  unlikely  that  two  outputs,  say,  would  be 
identical.  One  may  be  a  copy  of  the  other,  in  which  case  it  should  be  named  accordingly 
as  "copy_of_  ...".  The  given  sets  corresponding  tp  external  inputs  and  outputs  are 
generated  from  external  entities,  while  those  corresponding  to  internal  inputs  and  outputs 
are  generated  at  the  same  time  as  the  schema  that  uses  them  using  this  partial  translation 
itself. 

The  schema  is  given  the  empty  predicate.  This  is  because  information  relating  to  the 
predicate  does  not  appear  on  a  data  flow  diagram  but  must  be  obtained  from  other 
sources. 
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The  process  "Register_new_Customer"  from  the  Bank  example  gives  rise  to  a  schema  but 
no  additional  given  sets  (as  there  are  no  internal  inputs  or  internal  outputs).  The  schema 
is  given  the  same  name  as  the  process.  This  process  affects  the  single  "Customers"  data 
store,  and  has  one  input,  namely  a  customer’s  name. 

Each  datastore  gives  rise  to  a  schema  and  a  given  set,  which  is  needed  to  introduce  the 
type  of  the  contents  as  the  form  of  the  information  held  in  the  store  is  not  known  from  the 
data  flow  diagram. 

_  trans_store  . _ . 

trans_pars 

d_e  m  store  (  Q datastore  ) 

z_e  *  {  box  (  0 schema  )  )  u  {  given_set  (  store_name  “  "_type"  )  } 
where 

I  schema 
datastore 


n  ”  store_name 

sig  -  {  dec  (  store_name  “  "_contents", 

power set  (  given  (  store_name  “  "_t ype”  )  )  )  } 

pred  ~  empty 

• 

The  schema  generated  in  this  case  has  the  same  name  as  the  datastore.  The  contents  of 
the  datastore  do  not  appear  on  the  diagram,  so  a  contents  list  is  inserted  and  a 
corresponding  given  set  produced.  This  will  need  to  be  instantiated  later.  The  contents 
are  given  a  powerset  type,  that  is,  the  contents  of  a  datastore  are  assumed  to  be  a  set  of 
things.  As  in  the  case  of  a  process,  the  schema  generated  has  an  empty  predicate. 

The  datastore  from  the  Bank  example  produces  a  schema  and  one  given  set.  The  schema 
represents  the  state  data  for  the  system.  This  data  consists  of  a  set  of  "Customers_type". 

Bringing  this  all  together  gives  the  following  function  to  translate  the  diagram  elements 
of  a  given  diagram: 

translate_element  mm  X  d_e  :  DFD_element;  diagram  :  DFD  • 

(  U  z_e  :  F  z_element  I  trans_ext  v  trans jproc  v  trans_store  •  z_e  ) 

The  function  to  translate  a  data  flow  diagram  into  a  Z  specification  simply  translates  each 
element  of  the  diagram  in  turn: 

translate  “Id:  DFD  •  U  {  e  :  d.  elements  •  translate_element  (e,d)  } 

The  translation  of  the  Bank  example  is  as  follows.  The  external  entity  gives  rise  to  one 
given  set: 

translate_element  (ext  Customer,  Bank)  -  {  given_set  ("Customer_name”)  ) 

The  process  gives  rise  to  one  schema: 

translate_element  (  proc  p.  Bank  )  -  (  box  (s)  ) 
where 

I  s  :  schema 


s.n  -  "Register_new_Customer" 

s.sig  m  {  inc  (  "A Customers ”  ), 

dec  (  "Customer_name?”,  given  (  ”Customer_name_type "  )  )  } 

s.pred  -  empty 

The  datastore  gives  rise  to  one  schema  and  one  given  set: 


11 


translate_element  (  store  d,  Bank  )  - 

(  box  (p) ,  given_set  (  " Customers_type "  )  } 

where 

p  :  schema 

p.n  ~  " Customers " 

p.sig  -  {  dec  (  "Customers_contents", 

powerset  (  given  (  "Customers_type"  )  )  )  } 

p.pred  m  empty 

There  is  a  total  of  two  schemas  and  two  given  sets.  When  displayed  as  a  Z  specification, 
the  result  will  be  as  follows: 

f  Cust ome r_name_ type ,  Customers_type  ] 

r  Customers  , 

Customers_contents  :  P  Customers_type 


_  Register_new_Customer  . 

A Customers 

Customer_name?  :  Customer_name_type 

1 

The  translation  developed  in  this  section  produces  a  skeleton  Z  specification.  This  needs 
to  be  instantiated  by  defining  in  more  detail  the  types  of  data  actually  used.  The  required 
information  must  be  obtained  from  elsewhere  as  a  data  flow  diagram  cannot  provide  the 
necessary  information.  The  translation  scheme  provides  a  useful  way  of  using  a  diagram 
to  produce  a  well-structured  Z  specification. 

Translation__rules  keeps  trans_ext,  trans jproc,  trans_store, 

translate  element,  translate 
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5.  Checking  Compatibility 


Data_flow_diagram  :Module 

Z_specification  :Module 

Translation_rules  :Module 

1 

This  section  defines  a  relation,  represents,  which  says  what  it  means  for  a  data  flow 
diagram  and  a  Z  specification  to  represent  the  same  system.  The  complete  Z  specification 
is  not  needed  to  check  this  compatibility.  This  is  because  a  data  flow  diagram  does  not 
contain  any  information  about  predicates.  All  that  is  needed  of  the  Z  specification  is  the 
mapping  from  identifiers  that  appear  in  the  specification  to  their  types.  This  mapping  will 
be  called  a  moduie_spec.  Such  a  mapping  is  produced  by  Zadok  for  each  separate 
document  (or  module)  of  Z  successfully  type-checked,  and  forms  the  Z  language 
specification  of  the  module. 

I  module_spec  :  P  (identifier  ■+*  type) 

The  relation  is  defined  in  parts,  in  a  similar  manner  to  the  translation  function.  That  is,  it 
considers  each  son  of  diagram  element  in  turn.  A  module  specification  is  compatible  with 
an  external  entity  if  all  the  names  associated  with  that  entity  are  in  the  specification;  with 
a  datastore  if  a  schema  with  the  same  name  is  in  the  specification;  and  with  a  process  if  a 
schema  with  the  same  name  and  appropriate  signature  is  in  the  specification. 

I  _  partially_represents  _  ;  DFD_element  «-»  module_spec 

The  parameters,  that  is,  a  diagram  element  and  a  module  specification,  are  gathered  into 
the  following  schema: 

_  part _pars  | 

I  d_e  :  DFD_element 
I  m_s  :  module_spec 


External  entities  are  dealt  with  first.  Each  name  associated  with  the  external  entity  must 
be  in  the  module  specification. 

_  part_ext  _ , 

I  part _pars 


d_e  €  mg  ext 
( ext _1  d_e)  .names  c  dom  m_s 

For  a  datastore  and  a  module  specification  to  be  compatible  there  must  be  a  schema  with 
the  same  name  as  the  datastore. 

_  part_store  - 
part _pars 


d_e  e  mg  store 

(store"1  d_e) ,store_name  e  dom  m_s 

m_3  (  (store"1  d_e)  ,store_name  )  e  mg  schema_type 
~~  ~  1 

For  a  process  and  a  module  specification  to  be  compatible  there  must  be  a  schema  with 
the  same  name  as  the  process  and  with  an  appropriate  signature.  An  additional  function  is 
needed  to  flatten  the  signature  of  a  schema,  as  operations  are  often  defined  in  parts  using 
several  schemas  and  all  the  identifiers  from  all  the  parts  need  to  be  considered.  For 
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example,  all  references  to  unchanged  datastores  may  be  in  one  schema,  which  is  then 
included  in  the  schema  defining  the  operation.  These  datastores  must  be  checked  to 
ensure  that  the  operation  is  compatible  with  the  diagram. 


flatten  :  signature  — *  F  identifier 


V  sign  :  signature  • 

flatten  sign  -  {  i  :  identifier;  t  :  type  I  dec  (i,t)  e  sign  •  i  }  u 
U  {  name  :  schema_name;  s  :  schema  /  inc  ( name )  e  sign  a  s.n  -  name 
•  (  name  )  u  flatten  (  s.sig  )  } 

This  function  retrieves  all  the  identifiers  present  in  a  schema  signature  together  with  all 
those  implicitly  present  by  virtue  of  a  schema  inclusion. 

r  part _proc  —  ■-  | 

part jpars 

d_e  e  mg  proc 

m_s  (  (procT*  d_e)  .process_name  )  ■  powerset  (schema__type  (sign)) 
where 

I  sign  :  signature;  ids  :  F  identifier 


ids  -  flatten  sign 

V  data_flow;  datastore 

I  destination  «*  d_e  a  origin  -  store  (  Qdatastore  ) 
a  -»  (  3  data_flow'  •  origin'  m  d_e  a  destination'  m  origin) 

•  "S"  *  store_name  e  ids 

V  data  flow;  datastore 

I  destTnation  -  store  (  Bdatastore  )  a  origin  -  d_e 

•  "A "  “  store_name  €  ids 

V  data_flow  /  destination  -  d_e  a  origin  e  mg  ext 

•  label  ‘  e  ids 

V  data  flow  I  destination  e  mg  ext  a  origin  «  d_e 

•  label  "  "/"  «  ids 

V  data_flow 

I  destination  «  d_e  a  origin  e  rng  proc 
v  destination  €  rng  proc  a  origin  -  d_e 

•  label  e  ids 

■ 

For  each  data  flow  representing  a  look  up  of  state  data,  that  is,  the  flow  goes  from  a 
datastore  to  the  process  and  there  is  no  flow  from  the  process  back  to  the  same  datastore, 
the  flattened  signature  of  the  schema  must  include  "Sstore_name".  For  each  data  flow 
representing  a  change  of  state  data,  that  is,  the  flow  goes  from  the  process  to  a  datastore, 
the  flattened  signature  must  include  "Astore_name".  For  each  input,  internal  input,  output 
and  internal  output,  the  flattened  signature  must  contain  an  identifier  the  same  as  the 
label  on  the  data  flow,  decorated  with  a "?"  for  inputs  and  a "!"  for  outputs. 

Bringing  this  all  together  gives  the  following  definition  for  partial  representation: 

V  part _j pars 

•  dja  partially_represents  m_s  O  partjex t  v  part_store  v  part _pro c 

And  for  the  overall  relation, 

I  _  represents  _  :  DFD  h  module_spec 


V  d  :  DFD;  m  :  module_spec 
•  d  represents  m  4* 

U  {  d_e  :  d. elements;  ms  :  module_spec 
I  d_e  partially_represents  ms  *~ms  )  c  m 

This  relation  says  simply  that  a  diagram  is  related  to  a  module  specification  if  that 
specification  contains  all  the  sub-specifications  that  are  related  to  each  diagram  element. 
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Relationship  keeps  module  spec ,  partjext,  part_store,  flatten,  part_proc, 

partially_represents,  represents 
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6.  Rules  for  Generating  a  Data  Flow  Diagram  from  a  Z  Specification 


Data_flow_diagram  :Module 

Z_specification  :Module 

Relationship  :Module 

This  section  defines  a  function,  generate,  which  generates  a  data  flow  diagram  from  a  Z 
specification.  A  Z  specification  based  on  an  example  in  [6]  will  be  used  to  illustrate  the 
process.  This  example  specification  is  of  a  symbol  table,  with  two  operations  defined  on 
it:  one  to  add  an  entry  to  the  table,  and  one  to  look  up  the  value  of  a  symbol  from  the 
table.  Two  sets  are  introduced,  representing  the  symbols  held  in  the  table  and  their 
values. 

[  SYM,  VAL  J 

The  symbol  table  itself  is  just  a  set  of  SYM- VAL  pairs: 

—  Symbol_Table  t 

3t  :  P  (  SYM  X  VAL  ) 


The  first  operation  is  to  update  the  symbol  table  with  a  new  SYM- VAL  pair: 

_  Update  i 

I  A  Symbol_  Tabl  e 
I  sym?  :  SYM 
val?  :  VAL 


st'  m  st  ©  {  sym?  *  val?  } 


The  second  operation  looks  up  the  value  of  a  symbol  in  the  symbol  table: 

_  Lookup  t 

I  ESymbol_Table 
I  aym?  ;  SYM 
I  val!  :  VAL 


sym?  €  dom  fat) 
val!  -  at  faym?) 


The  diagram  generating  function  is  again  defined  in  parts,  each  taking  a  Z  specification 
and  generating  part  of  the  data  flow  diagram.  Datastores  are  generated  from  those 
schemas  defining  (part  of)  the  state,  processes  from  those  schemas  defining  operations  on 
the  state,  and  external  entities  from  the  inputs  and  outputs  of  the  schemas  defining 
operations.  Information  from  the  signatures  of  the  schemas  defining  operations  is  used  to 
generate  the  data  flows. 

One  data  store  is  generated  for  each  schema  representing  pan  of  the  state. 
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gen_dat as tores  :  z_specification  — *  P  datastore 

V  z  :  z_specification  •  gen_datastores  z  m 
{  schema/  datastore 
I  box  (  B schema  )  e  z 

V  el  :  sig  I  el  €  mg  inc  •  hd  ( incT 1  el)  «  f  'A',  'S'  / 
store_name  -  n 
•  0 datastore  ) 

State  schemas  ate  identified  by  the  absence  of  any  schemas  representing  a  change  of  state 
in  its  signature.  Each  datastore  is  given  the  same  name  as  the  relevant  schema.  Any 
predicate  in  the  schema  is  ignored. 

In  the  example  Z  specification,  one  datastore  is  generated  from  the  schema 
Symbol_Table. 

Id  :  datastore 

d.store_name  •  "Symbol_Table" 

This  datastore  is  given  the  same  name  as  the  schema. 

An  external  entity  is  generated  for  each  input  and  output  in  a  schema  defining  an 
operation  on  the  state.  Each  external  entity  generated  will  have  one  name  associated  with 
it.  This  could  be  relaxed  if  required  so  that  no  external  entities  are  generated.  Instead  data 
flows  representing  inputs  and  outputs  to  the  system  could  be  left  with  one  end  unattached 
to  any  diagram  element,  and  appropriate  external  entities  added  using  information 
obtained  from  other  sources. 

gen_external_entities  :  z_specification  -+  P  external_entity 

V  z  :  z_specification  •  gen_external_entities  z  - 

{  schema/  external_entity /  i  :  identifier/  ty  :  type 
I  box  (  0 schema  )  €  z 

last  i  e  {  )  a  dec  (  i,  ty  )  e  sig 

names  -  {  front  i  ) 

•  Bexternal_entity  ) 

Inputs  and  outputs  are  found  by  looking  for  identifiers  ending  with  a  "?"  or  "!"  which 
appear  in  the  signature  of  a  schema.  The  type  of  the  identifier  is  irrelevant,  as  this 
information  does  not  appear  on  a  data  flow  diagram. 

In  the  example  Z  specification,  there  are  two  operations  defined  on  the  state,  namely 
update  and  Lookup.  Each  of  these  generates  the  same  two  external  entities.  Thus,  the 
generated  diagram  will  contain  the  following  two  external  entities: 

I  el  :  external__entity  e2  :  external_entity 

el. names  m  {  " sym "  )  e2. names  ”  {  "val"  ) 

A  process  is  generated  for  each  schema  that  defines  an  operation  on  the  state.  The 
generated  process  will  have  the  same  name  as  the  schema,  the  inputs  will  be  those 
identifiers  which  end  with  "?”  in  the  schema,  and  the  outputs  those  which  end  with "!". 
The  order  of  the  inputs  and  outputs  does  not  matter.  It  is  impossible  to  tell  in  general 
from  the  Z  specification  whether  an  identifier  which  does  not  end  in  tt?"  or  "!"  is  an 
internal  input  or  an  internal  output,  so  no  attempt  is  made  to  distinguish  the  two.  All 
identifiers  which  are  not  inputs,  outputs  or  inclusions  are  treated  as  internal  inputs  or 
outputs.  Hie  predicate  part  of  the  schema  is  ignored. 
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gen_processes  :  z_specification  - *  IP  process 


V  z  :  z_specification  •  gen jprocesses  z  ■ 

{  schema;  process 
Ibox  (  8 schema  )  e  z 

3  sn  :  schema_name  I  hd  sn  e  {  'A',  'E'  )  •  inc  (  sn  )  e  sig 
process_name  ■  n 

mg  inputs  m  {  i  :  identifier;  ty  :  type 

I  last  i  -  '?'  a  dec  e  sig 

•  /root  i  } 

rng  outputs  -  {  i  :  identifier;  ty  :  type 

I  last  i  *  ' a  dec  (i,ty)  e  sig 
•  front  i  } 

rng  int_inputs  u  rng  int_outputs  ■ 

{  i  :  identifier;  ty  :  type 
I  last  i  C  {  '!'  )  a  dec  (i,ty)  €  sig 

•  i  ) 

•  ^process  } 

A  check  is  made  that  the  schema  does  represent  an  operation,  by  requiring  that  there 
should  be  at  least  one  inclusion  in  the  signature  which  represents  a  change  of  state.  The 
example  Z  specification  generates  two  processes,  one  for  each  operation.  These  are  as 
follows: 


pi  :  process 

p2  :  process 

pl.process_name  -  " Update " 

p2 .processjname  *  "Lookup" 

pi. inputs  ”  (  ”sym”,  ”val "  ) 

p2. inputs  "  (  "sym"  > 

pi. outputs  -  0 

p2 .outputs  -  (  " val ”  ) 

pl.int_inputs  m  0 

p2.int_inputs  -  0 

pi  .int^outputs  -  0 

p2.int__outputs  -  0 

Data  flows  are  generated  for  each  read  of  the  state  (that  is,  for  every  "Edatastore”  in  a 
signature  of  a  schema  defining  an  operation),  for  each  state  change,  and  for  each  input 
and  output.  There  is  insufficient  information  to  join  up  internal  flows,  so  these  cannot  be 
filled  in  on  the  generated  diagram  but  must  be  filled  in  by  hand  afterwards.  This  is 
because  internal  flows  are  just  undecorated  identifiers,  and,  if  the  same  identifier  appears 
in  four  schemas,  say,  there  is  no  way  of  knowing  which  two  pairs  are  joined  by  the 
dataflow,  nor  in  which  direction  the  data  are  flowing.  The  four  known  cases  will  be 
defined  in  turn. 

Each  read  of  the  state  generates  a  flow  from  the  datastore  to  the  process  concerned. 

gen_data_flows_l  mm  X  z  :  z_specification  • 

{  schema;  data-flow;  i  :  identifier 
I  inc  i  €  sig  a  hd  i  -  'S' 
origin  -  store  (  4  ds  :  (gen_datastores  z) 

I  ds.store_name  ■  tl  i  •  ds  ) 

destination  *  proc  (up:  (gen processes  z) 

I  p  ,process_name  m  n  •  p  ) 

label  -  "" 

•  Qdata_flo*r  I 

Reads  are  identified  by  the  presence  of  an  inclusion  of  the  form  "Eschema.name".  The 
origin  of  the  flow  is  the  store  with  the  corresponding  name,  and  the  destination  the 
process  with  the  same  name  as  the  schema  in  which  the  inclusion  was  found.  No  label  is 
put  on  the  data  flow. 

Each  state  change  generates  a  flow  from  the  process  concerned  to  the  relevant  data  store. 
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gen  da t a_flows_2  ■■  X  *  :  z_specification  • 

7  schema;  i  :  identifier 7  data-flow 
I  inc  i  €  aig  a  Jld  i  ■  'A'  ~ 

destination  -  store  (  u  ds  :  <gen_datastores  z) 

I  ds . store_name  -  tJ  i  •  ds  > 
origin  ■  proc  f  |i  p  :  (gen _processes  z) 

I  p.process_name  -  n  •  p  ) 

label  - 

•  0data_/iov  i 

State  changes  are  identified  by  the  presence  of  an  inclusion  of  the  form 
"Aschemajname".  The  origin  of  die  flow  is  the  process  with  the  same  name  as  the 
schema  in  which  the  inclusion  was  found  and  the  destination  the  store  with  the 
corresponding  name.  No  label  is  put  on  the  data  flow. 

Data  flows  are  generated  for  each  input: 

gen_data_flows_3  mm  X  z  :  z_apecification  • 

(schema;  i  :  identifier;  data_flow 
I  i  e  dom  (  dec r*  I  sig  1  )  a  iast  i  -  '?' 

origin  m  ext  (  |i  e  :  (gen_external  entities  z) 

I  e. names  -  (front  1}  •  e  ) 

destination  -  proc  (  \i  p  :  (gen_processes  z) 

I  p.process_name  -  n  •  p  ) 

label  m  front  i 

•  9data_flow  } 

Inputs  are  identified  by  the  existence  of  a  declaration  in  a  schema,  with  identifier  ending 
with  a  "?".  The  origin  of  the  flow  is  the  external  entity  with  the  identifier  without  the  "?" 
as  its  associated  name,  which  is  also  the  label  put  on  the  data  flow.  The  destination  is  the 
process  with  the  same  name  as  the  schema  in  which  the  input  was  found. 

Data  flows  are  generated  for  each  output: 

gen_data_flows_4  —  k  z  :  z_specification  • 

{  schema;  i  :  identifier;  data_flow 
I  i  €  dom  (  dec-1  I  sig  1  ;  a  last  i  -  ' !' 
destination  «  ext  (  4  e  :  (gen__external  entities  z) 

I  e. names  ■  (front  1)  •  e  ) 
origin  *  proc  (  \i  p  :  (gen _processes  z) 

I  p.process_name  m  n  •  p  ) 

label  m  front  i 

•  Odata_flow  } 

Outputs  are  identified  by  the  existence  of  a  declaration  in  a  schema,  with  identifier 
ending  with  a  The  destination  of  the  flow  is  the  external  entity  with  the  identifier 
without  the  "!"  as  its  associated  name,  which  is  also  the  label  put  on  the  data  flow.  The 
origin  is  the  process  with  the  same  name  as  the  schema  in  which  the  output  was  found. 

Bringing  this  all  together  into  one  rule  gives: 

]  gen_data_flo«s  :  z_specification  —*  IP  data_flow 


V  z  :  z_specification 

•  gen_data_ flows  z  -  (  gen_da t a_flows_  1  z  ) 

~  u  (  geiT_datarmflows^_2  z  ) 

u  (  gen_data~flows~3  z  ) 
u  (  gen_dataTflows_4  z  ) 

The  example  Z  specification  generates  six  data  flows.  The  operation  update  generates 
(me  from  the  update  process  to  the  datastore.  It  also  generates  one  from  the  external 
entity  with  name  "sym",  and  one  from  the  external  entity  with  name  "val".  The  operation 
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Lookup  generates  one  data  flow  from  the  datastore  to  the  lookup  process,  one  from  the 
external  entity  with  name  "sym"  and  one  to  the  external  entity  with  name  "val". 

Bringing  all  the  partial  generating  functions  together  gives  the  following  function  for 
generating  a  data  flow  diagram  from  a  Z  specification,  provided  that  the  specification  is 
written  in  the  style  of  state  schemas  and  operations  on  (part  of)  the  state: 

|  generate  :  z_specification  ■+»  DFD 


V  z  :  z_specification  • 
generate  z  -  d 
where 
I  d  ;  DFD 


d.  elements  -  store  I  gen_datastores  z  I 

u  ext  I  gen_external_entities  z  1 
u  proc  f  gen jproceases  z  ) 
d. flows  m  gen_data_ flows  z 


The  diagram  resulting  from  the  example  developed  in  this  section  is  shown  in  Figure  2. 

Translation  rules  have  been  developed  not  only  for  developing  a  Z  specification  from  a 
data  flow  diagram  (in  Section  4),  but  also  for  generating  a  data  flow  diagram  from  a  Z 
specification,  described  in  this  section.  This  latter  is  a  useful  way  of  illustrating  a  Z 
specification  so  that  the  structure  becomes  clear.  The  diagram  produced  will  aid 
understanding  of  the  specification  and  will  help  with  the  process  of  validating  the 
specification. 

Generating_rules  keeps  gen_datastores,  gen_external_entitJ.es , 

gen jprocesses,  genJdata_flows,  generate 
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Figure  2  The  Generated  Data  Flow  Diagram 
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7.  Conclusions 


This  report  has  presented  three  approaches  to  using  a  formal  language,  Z,  with  a 
structured  diagrammatic  technique,  data  flow  diagrams.  These  approaches  are  translating 
data  flow  diagrams  into  a  Z  specification,  checking  consistency  of  a  diagram  and  a  Z 
specification  using  the  relationship  between  them,  and  generating  a  diagram  from  a  Z 
specification  written  in  a  state-based  style. 

A  particular  interpretation  has  been  put  on  both  data  flow  diagrams  and  Z,  and  this  needs 
to  be  validated.  However,  it  is  based  on  the  standard  style  of  using  Z,  that  is,  using 
schemas  to  specify  both  the  state  and  operations  on  that  state.  Translating  a  data  flow 
diagram  into  Z  produces  only  an  outline  specification.  This  specification  should  be  used 
as  a  starting  point,  a  way  of  structuring  a  specification.  Conversely,  generating  a  data 
flow  diagram  from  a  Z  specification  may  lead  to  a  large  diagram.  This  would  occur  in  the 
case  where  an  operation  is  defined  in  parts,  each  part  in  a  separate  schema.  If  the 
complete  operation  only  were  used  in  the  generation  process  then  a  sensible  diagram 
would  result.  If,  however,  diagram  elements  were  generated  for  each  part,  then  the 
resulting  diagram  would  be  cluttered.  A  useful  approach  would  be  to  use  the  separate 
pans  of  an  operation  to  generate  a  separate  diagram  describing  just  that  operation. 

The  data  flow  diagram  may  be  considered  to  be  a  high  level  overview  of  the  system. 
Therefore,  it  is  not  surprising  that  a  small  amount  of  Z  is  produced.  The  usefulness  of  the 
relationship  defined  is  that  it  provides  a  mechanical  check  that  the  high  level  overview 
given  by  a  data  flow  diagram  is  consistent  with  the  more  detailed  description  given  by  a 
Z  specification.  There  are  other  information  flows  contained  in  a  Z  specification,  for 
example,  the  inclusions  of  schemas  within  other  schemas.  A  similar  diagram  to  a  data 
flow  diagram  could  be  automatically  generated  to  produce  a  "usage  tree"  of  the 
specification.  This  would  be  of  great  help  to  reviewers  of  the  specification  as  it  would 
help  them  to  navigate  through  the  specification  and  keep  track  of  the  usage  of  schemas. 

The  specifications  given  in  this  report  could  be  used  to  build  a  tool  to  carry  out  the  three 
techniques,  preferably  as  part  of  an  integrated  support  tool.  However,  data  flow  diagrams 
are  only  one  of  a  number  of  techniques  used  in  a  structured  method  such  as  SSADM. 
Other  diagrammatic  techniques  include  entity  life  histories  and  logical  data  structuring 
(also  called  entity  modelling).  This  work  with  data  flow  diagrams  and  Z  has 
demonstrated  the  usefulness  and  practicality  of  combining  structured  and  formal 
methods,  and  a  follow-on  to  this  would  be  to  carry  out  similar  studies  for  the  other 
diagrammatic  techniques.  The  eventual  aim  is  a  toolset  which  will  allow  outline  formal 
specifications  to  be  generated  automatically  from  a  set  of  diagrams,  which  may  then  be 
used  in  a  formal  development,  if  desired,  of  the  required  system.  Alternatively,  the 
mathematical  specifications  may  be  used  to  prove  properties  of  the  system.  Generating 
diagrams  from  a  formal,  mathematical  specification  will  aid  validation  of  that 
specification  as  diagrams  are  easier  to  understand  than  a  mathematical  specifiation,  and 
are  not  so  daunting  at  first  sight. 

This  work,  by  providing  a  set  of  formal  rules  to  translate  a  diagram  into  a  formal 
language,  has  resulted  in  the  diagrams  themselves  becoming  formal  objects,  with  all  the 
associated  benefits  of  precision  and  lack  of  ambiguity.  Adding  this  formal  basis  has  not 
detracted  from  the  readability  of  the  diagrams.  This  demonstrates  that  formal  languages 
are  not  necessarily  harder  to  understand.  It  is  the  mathematical  symbols  of  current  formal 
languages  such  as  Z  that  make  them  seem  more  daunting  than  they  really  are. 


22 


References 

[1]  G  P  Randell,  "The  Integration  of  Structured  and  Formal  Methods",  RSRE 
Memorandum  No.  4293,  June  1989 

[2]  J  M  Spivey,  "The  Z  Notation:  A  Reference  Manual",  Prentice-Hall  International 
Series  in  Computer  Science,  1989 

[3]  G  Longworth  and  D  Nicholls,  "SSADM  Manual",  Version  3.0,  NCC,  December  1986 

[4]  Yourdon  International  Ltd.,  "The  Yourdon  Structured  Method  (YSM)",  Yourdon, 
1988 

[5]  Systems  Designers  Scientific  Ltd.,  "CORE  -  the  Method",  Issue  1.0,  November  1985 

[6]  I  Hayes  (Editor),  "Specification  Case  Studies",  Prentice-Hall  International  Series  in 
Computer  Science,  1987 

[7]  G  P  Randell,  "Zadok  User  Guide",  RSRE  Memorandum  No.  4356,  January  1990 


23 


THIS  PAGE  IS  LEFT  BLANK  INTENTIONALLY 


REPORT  DOCUMENTATION  PAGE 


DRIC  Reference  Number  (if  known) . 


Overall  security  classification  of  sheet  ... _ ... . . UNCLASSIFIED - - - - - - - .... 

(As  far  as  possble  this  sheet  should  oontaln  only  unclassified  Information.  If  It  Is  necessary  to  enter  classified  Information,  the  field  conoamed 
must  be  marked  to  Indteate  the  classification  eg  (R),  (C)  or  (S). 


Originators  Referenoe/Report  No. 

REPORT  90019 


Originators  Name  and  Location 

RSRE,  St  Andrews  Road 
Malvern,  Worcs  WR14  3PS 


Monitoring  Agency  Name  and  Location 


Month 

OCTOBER 


Year 

1990 


TRANSLATING  DATA  FLOW  DIAGRAMS  INTO  Z 
(AND  VICE  VERSA) 


Report  Security  Classification 

UNCLASSIFIED 


Foreign  Language  Title  (in  the  case  of  translations) 


Title  Classification  (U,  R,  C  or  S) 

U 


Agency  Reference 


Contract  Number  and  Period 


Project  Number 


Other  References 


Authors 


RANDELL,  G  P 


Pagination  and  Ref 

23 


Abstract 


This  report  describes  the  results  of  work  into  the  integration  of  structured  and  formal  methods,  in 
particular,  data  flow  diagrams  and  Z.  Data  flow  diagrams  are  given  a  formal,  mathematical  basis  by 
defining  rules  to  translate  these  diagrams  into  Z.  Rules  are  also  given  for  generating  a  data  flow  diagram 
from  a  Z  specification,  and  for  checking  the  compatibility  of  a  data  flow  diagram  and  a  Z  specification. 


Abstract  Classification  (U.R.C  or  S) 


Dfebbution  Statemsnt  (Enter  any  limitations  on  the  dfetrbutlon  of  ths  document) 
UNLIMITED 


THIS  PAGE  IS  LEFT  BLANK  INTENTIONALLY 


